home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1560 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.9 KB  |  91 lines
  1. Path: cs.uni-sb.de!neis
  2. From: neis@cs.uni-sb.de (Stefan Neis)
  3. Newsgroups: gnu.g++.help,comp.lang.c++
  4. Subject: Argument matching
  5. Date: 11 Jan 1996 10:43:42 -0500
  6. Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
  7. Sender: daemon@cis.ohio-state.edu
  8. Distribution: world
  9. Message-ID: <9601111542.AA05990@crypt5.cs.uni-sb.de>
  10.  
  11.                Hi there,
  12.  
  13. I'm having an ugly problem with templates and inheritance. I mirrored
  14. my problem by a less complicated --though useless --  example which
  15. avoids using templates. Assume the following class hierarchie:
  16.    A    B
  17.     |
  18.        Bderived
  19. and let there be a constructor which makes a Bderived from A.
  20.  
  21. I hoped, the compiler would automatically convert A to Bderived (user
  22. defined conv.) and then convert this to B (standard conversion, isn't
  23. it?) if I give an "A" as argument to a function expecting a "B". But
  24. this is obviously not the case -- neither with g++ nor with CC -- (see
  25. the following example), so I assume that a user defined conversion
  26. always has to be the last conversion that is applied to an
  27. argument. Is this assumption correct (Couldn't find anything on this
  28. in Stroustrup's "The C++ Programming Language")? If so, are there
  29. plans to change this? I would find this kind of conversions extremely
  30. useful for using templates, e.g. (to get to my original example) if
  31. you want a "vector<int>" and a "vector<complex>", where complex is
  32. intended to be some class realizing complex numbers, you would like to
  33. have a automatic conversion from "vector<int>" to "vector<complex>"
  34. and maybe "vector<complex>" should have additional functions. So I
  35. wrote a "base_vector<T>" (corresponding to B) where all common
  36. functions are included, vector inherits from this, and is specialised
  37. for complex (corresponding to Bderived) and now the automatic
  38. conversion from vector<int>(corresponding to A) to vector<complex>
  39. doesn't work as I hoped it to do. Any Suggestions on how to circumvent
  40. this problem? Is my problem really that unusual?
  41.  
  42.     Stefan Neis
  43.  
  44. P.S.: I suppose, I could additionally define a "cast operator" from A to
  45.     the base_class B (constructor won't do, since B is intended
  46.     to be a template class...), but if I would derive Bderived by
  47.     several steps from B this would lead to programming the "same"
  48.     cast operator over and over again....
  49.  
  50. --------------------- EXAMPLE -----------------------------------
  51. class A
  52. {
  53.   int i;
  54. public:
  55.   A(){}
  56.   A(int x){i=x;}
  57.   int get() const {return i;};
  58.   ~A(){}
  59. };
  60.  
  61. class B
  62. {
  63.   long i;        // using long instead of "complex" to get
  64.             // something  that compiles more easily.
  65. public:
  66.   B(){}
  67.   B(int x){i=x;}
  68.   ~B(){}
  69.  
  70.   friend B operator * (const B&, const B&);
  71. };
  72.  
  73. class Bderived: public B
  74. {
  75. public:
  76.   Bderived():B(){}
  77.   Bderived(int x):B(x){}
  78.   Bderived(const A & x):B(x.get()){}
  79.   ~Bderived(){}
  80. };
  81.  
  82. main()
  83. { A testA(4);
  84.   Bderived testBder(5);
  85.   B testB;
  86.   
  87.   testB = Bderived(testA) * testBder;    // this -- of course -- does work.
  88.   testB = testA * testBder;        // this won't compile at all.
  89. }
  90.  
  91.